1. Field of the Invention
The invention relates to the control of distributed processing and application interoperability in a communication system. Particularly, the invention relates to a method for the construction and execution of distributed workflows in a communication system.
2. Description of the Related Art
Before the introduction of application interoperability architectures and software, applications were designed as monolithic systems operating only within a given hardware and operating system environment. All too often it was very difficult to determine where a given application starts and ends, hence also control execution sequences consisting of multiple applications. The applications formed amoeba like structures without clear interfaces and boundaries.
Facilitated by object-oriented and web services technologies and interoperability solutions emerged new applications can be defined as separate components that are reusable in a variety of business processes. In this approach, a user interface implementing a given workflow needs to be designed as a new business process is introduced. It became also possible to introduce wrapper applications to existing legacy applications. The purpose of a wrapper is to make an existing legacy application to look like a separate reusable component or a set of reusable components. Examples of interoperability architectures comprise, for example, the Common Object Request Broker Architecture (CORBA™) defined by Object Management Group Inc, Distributed Common Object Model (DCOM) defined by Microsoft Corporation and web services technologies. It should be noted that the use of workflows, wrappers and interoperability architectures is by no means restricted to business information technology and business applications. Workflows may also be applied in industrial process control, control of mechanical and electrical devices and communication network management. Workflows may be defined implicitly using a user-interface software component programmed, for example, with VISUAL BASIC®. Workflows may also be defined with a workflow language such as XLANG defined by Microsoft Corporation, Web Service Flow Language (WSFL) defined by IBM inc or Semantic Markup for Web Services (OWL-S) defined by World Wide Web Consortium (W3C). The acronym OWL stands for Ontology Web Language. The OWL-S is specified in the Defense Advanced Research Projects Agency (DARPA) Agent Markup Language (DAML) Program document OWL-S 1.1, November 2004. Workflows comprise a number of task, which comprise, for example, the execution of a reusable software component with parameters, the values of which have been determined earlier in the execution of the workflow. Workflows also comprise functionalities familiar from programming languages such as branching conditions and looping.
In FIG. 1 there is illustrated a workflow comprising an arbitrary number of applications in prior art. In FIG. 1 there is illustrated at least an application 101, an application 102, an application 103, an application 104 and an application 105. The lower case letter n standing for an arbitrary integer indicates that there may be an arbitrary number of applications. The applications are arranged as a sequence. However, there is also illustrated a branching condition, which enables directly the stepping from application 102 to application 104. The workflow is defined, for example, using a Graphical User Interface (GUI). The workflow is specified, in other words, defined using a workflow language. The syntax of the workflow language may, for example, be based on the extensible mark-up language or any other known syntax for similar purposes, which may be parsed by an interpreter or a compiler.
FIG. 2 illustrates the execution of a workflow in a communication system in prior art. In FIG. 2 there is illustrated a workflow management node 250. There are also illustrated three application nodes communicating with workflow management node 250. There is an application node 252, an application node 254 and an application node 256. There may be also any number of application nodes as illustrated with the lower case letter n, which stands for an arbitrary integer. In FIG. 2 it is assumed that there is a workflow consisting of four applications. These applications are invoked sequentially one after another. The workflow specification indicating the execution of these four applications is stored in workflow management node 250. Initially the workflow specification instructs the workflow management node 250 to invoke an application in application node 252. The application invocation request and the accompanying response are illustrated with a double-ended arrow 201. The arrowhead pointing to application node 252 indicates the request and the arrowhead in the opposite direction indicates the response. Thereupon, workflow management node 250 determines from the workflow specification that a second application is to be invoked from application node 252. The application invocation and the associated response are illustrated with arrow 202. Next, workflow management node 250 determines that a third application is to be invoked in application node 254. The application invocation request and the accompanying response from the third application are illustrated with arrow 203. Eventually, the workflow management node 250 determines that a fourth application is to be invoked from application node 256. The application invocation request and the respective response message from the fourth application are illustrated with arrow 204.
The problem in prior art solutions is that a single workflow execution node introduces a single point of failure into the communication network. The workflow execution node must be replicated with a standby node, which becomes a costly solution. Additionally, a carrier grade platform is required in order to synchronize the states of the workflow execution node and the standby node in order to provide a hot-standby configuration. It is also likely that a single workflow execution node, whether replicated or not, is not a scalable solution. The workflow execution node becomes a bottleneck in the system, if a considerable number of workflows must be processed in a short time-frame.